Asset tracking system

ABSTRACT

An asset tracking system for tracking assets, for example, a vehicle, with an integrated topology that is configured minimize the complexity of the system by eliminating hardware duplication and sensing the ignition state while obviating the need to access the ignition switch circuit; the asset tracking system optionally including a loan obligation management system that is integrated with the asset recovery system which provides in-vehicle notifications of loan obligations for the asset upon which the loan obligation is based from a remote location directly to the asset.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an asset tracking system for trackingassets, for example, a vehicle, with an integrated topology that isconfigured minimize the complexity of the system by eliminating hardwareduplication and sensing the ignition state of the vehicle which obviatesthe need to access the vehicle ignition switch circuit; the assettracking system optionally including a loan obligation management systemthat is integrated with the asset recovery system which providesnotifications of loan obligations for the asset upon which the loanobligation is based and can even disable the vehicle from a remotelocation.

2. Description of the Prior Art

Various asset tracking systems are known in the art. Such asset trackingsystems are typically used to track vehicles. Examples of such assetrecovery systems that are used to track vehicles are disclosed in U.S.Pat. Nos. 5,223,844; 5,418,537; 6,025,774; 6,240,365; 6,249,217; and6,377,210, all hereby incorporated by reference. In addition OnStar¹in-vehicle security, communications, and diagnostics systems and LoJack²vehicle recovery systems are also known which can locate and track theposition of a vehicle and facilitate recovery of stolen vehicles. ¹OnStar is a registered trademark of General Motors Corporation² LoJackis a registered trademark of LoJack Corporation

In general, such asset recovery systems 20 are generally configured asillustrated in FIG. 1 normally include four (4) relatively autonomoussubsystems. The four (4) subsystems consist of an application subsystem22, a communications subsystem 24, a global positioning system (GPS)subsystem 26 and a power and input/output (I/O) subsystem 28. Oneproblem with known vehicle recovery systems relates to the level ofduplication of hardware components among the subsystems 22, 24, 26 and28. Such duplication increases the complexity and cost of such vehiclerecovery systems as well as the size of the device.

More particularly, a block diagram of the Application Subsystem 22 isillustrated in FIG. 2. As shown, the Application Subsystem 22 includes aCPU (computer processing unit) 30, peripherals 32, random access memory(RAM), flash memory 36 for storing the main software application 40 andpower source 38.

A block diagram of the GPS subsystem 26 is illustrated in FIG. 3. TheGPS Subsystem 26 includes another CPU 42, peripherals 44, GPSCorrelators 46, RAM 48, Flash Memory 50, Communications hardware 52 forcommunicating the GPS information to the Communications Subsystem 24, aGPS Antenna 52, a GPS RF Receiver 54 for receiving position informationfrom GPS satellites (not shown), and LDO Regulators 56.

A low drop out (LDO) regulator is a linear voltage regulator thatoperates even when the input voltage barely exceeds the desired outputvoltage. Such LDO regulators are known to be used with systems that aredriven by battery power sources, such as a vehicle.

FIG. 4 is a block diagram of the Communications Subsystem 24. TheCommunications Subsystem 24 includes a CPU 58, peripherals 60, a poweramplifier 62, RAM 64, and Flash Memory 66, Communications hardware 68for communicating with the GPS Subsystem 26, an antenna 70, an RFTransceiver 72 and LDO Regulators 74.

FIG. 5 illustrates a block diagram of the Power and I/O Subsystem 28.The Power and I/O Subsystem 28 includes power regulators 76, batterycharger 80, ESD (Electrostatic discharge) and Surge Protection 84. ThePower and I/O Subsystem 28 also includes software configured as I/Odrivers 78, battery charge protection 82 and over-current protection 86that is stored in the Application Subsystem Flash memory 36 (FIG. 2).

FIG. 6 illustrates the duplicated hardware and duplicated functionalitythat exists among the application subsystem 22, the communicationssubsystem 24, the GPS subsystem 26 and a power and I/O subsystem 28 inknown asset tracking systems. In particular, the duplicated hardware andfunctionality includes:

-   -   Duplicated CPUs: The application subsystem 22, the GPS subsystem        26 and the communications subsystem 24 each have a single        purpose CPU.    -   Duplicated Memory: The application subsystem 22, the GPS        subsystem 26 and the communications subsystem 24 all have their        own RAM and Flash memory devices for autonomous operation.    -   Duplicated Communication: The application subsystem 22, the GPS        subsystem 26 and the communications subsystem 24 each have        communication peripherals for state and data communication among        them.    -   Duplicated Power Components: Multiple LDOs and regulators are        required for autonomous power control.

There are other problems associated with known asset recovery systems.For example, such asset recovery systems need the operational state ofthe ignition system to operate properly. In some vehicles, such asmotorcycles, scooters, all terrain vehicles, and watercraft, access tothe vehicle ignition system is either unavailable or inaccessible. Assuch, asset recovery systems are generally unavailable for suchvehicles. Another problem with known asset recovery systems is a lack ofoptimization of system resources, for example, for loan obligationmanagement.

Thus, there is a need to simplify such asset recovery systems whichminimizes the complexity of the system and minimizes duplication ofhardware components to reduce the cost of such systems and obviates theneed to access the ignition circuit in order to make such asset recoverysystems available for vehicles with inaccessible vehicle ignitionsystems and provide remote management of the asset with respect to itsloan obligation.

SUMMARY OF THE INVENTION

The present invention relates to an asset tracking system for trackingassets, for example, a vehicle, with an integrated topology that isconfigured minimize the complexity of the system by eliminating hardwareduplication and sensing the ignition state of the vehicle whileobviating the need to access the ignition switch circuit; the assettracking system optionally including a loan obligation management systemthat is integrated with the asset recovery system which provides audiblenotifications of loan obligations for the asset upon which the loanobligation is based and can even disable the vehicle from a remotelocation.

DESCRIPTION OF THE DRAWING

These and other advantages of the present invention will be readilyunderstood with reference to the following specification and attacheddrawing wherein:

FIG. 1 is a high level block diagram of a known asset recovery system.

FIG. 2 is a block diagram of a known application subsystem that forms apart of the asset recovery system illustrated in FIG. 1.

FIG. 3 is a block diagram of a known GPS subsystem that forms a part ofthe asset recovery system illustrated in FIG. 1.

FIG. 4 is a block diagram of a known communication subsystem that formsa part of the asset recovery system illustrated in FIG. 1.

FIG. 5 is a block diagram of a known power and I/O subsystem that formsa part of the asset recovery system illustrated in FIG. 1.

FIG. 6 illustrates the overlap of the hardware components of the assetrecovery system illustrated in FIG. 1.

FIG. 7 is a block diagram of the integrated asset recovery system inaccordance with the present invention.

FIG. 8 is a schematic diagram of the integrated asset in accordance withthe present invention.

FIG. 9 is a software flow diagram for determining the whether to use ahard-wired ignition state or an “inferred” ignition state.

FIG. 10 is a software flow diagram for determining the state of theignition system.

FIG. 11 is a software flow diagram for managing an ultra-low power sleepmode.

FIG. 12 is a software flow diagram illustrating the GPS positioncalculation.

FIG. 13 is a software flow diagram of the main application statemachine.

FIG. 14 is a software flow diagram of the loan obligation managementsystem in accordance with one aspect of the present invention.

DETAILED DESCRIPTION

The present invention relates to an asset tracking system for trackingassets, for example, a vehicle, with an integrated topology that isconfigured minimize the complexity of the system by eliminating hardwareduplication and sensing the ignition state of the vehicle with two (2)wires over one or more sample periods that obviates the need to accessthe vehicle ignition switch circuit. FIGS. 7-13 illustrate theintegrated asset recovery system in accordance with the presentinvention. FIG. 14 illustrates an optional loan obligation managementsystem for use with the asset recovery system in accordance with anotheraspect of the invention.

The asset recovery system in accordance with the invention reducescomplexity relative to known asset recovery systems in several ways by:

-   -   Consolidating all subsystem CPU requirements.    -   Eliminating all subsystem intercommunication connections.    -   Consolidating all Flash and RAM memory requirements.    -   Consolidating power rails, switches, regulators and monitors.

Exemplary Hardware

Referring to FIG. 1, a block diagram of the asset recovery system inaccordance with the present invention is illustrated and identified withthe reference numeral 100. The asset recovery system 100 includes asingle CPU 102, for example, a Reduced Instruction Set Computer (RISC),Model ARM7 or ARM9, CPU. As mentioned above, the memory is consolidatedwith a single RAM memory 104 and a single Flash memory 106. As such, thesoftware applications, such as the main Application 105 and the GPSCorrelators 107, on the same memory device, namely, the Flash memory106. As far as communications ports, ports for inter-communicationbetween different subsystems have been eliminated. With the integratedsystem in accordance with the present invention, only two (2)communication ports are necessary. A Simple Sensor Interface (SSI) 108is required for interfacing an RF transceiver 109, which forms part of acellular subsystem, generally identified with the reference numeral 110(FIG. 8) with the CPU 102 (FIG. 7). The SSI port 108 may be on-board theCPU 102. The cellular subsystem also includes a cellular antenna 120 forreceiving and transmitting data between the asset recovery system 100and a remote device (not shown). The SSI protocol is a simplecommunications protocol designed for data transfer between computers oruser terminals and smart sensors. Another port, a universal asynchronousreceiver/transmitter (UART) 112 is used to interface a GPS receiver 114with the CPU 102. The UART 112 may be on board the CPU 102. The GPSreceiver 114 and a GPS antenna 116 form a GPS subsystem, generallyidentified with the reference numeral 118. Since only a single CPU 102is required, the number of associated CPU peripherals is reduced. Forexample, only a single peripheral 122 is required which includesperipheral devices and applications, such as an analog to digitalconverter (ADC) and a watchdog timer. The integrated asset recoverysystem 100 also minimizes the power supply requirements of the systemand only requires a single power amplifier 124 and a single LDOregulator 126.

A schematic of the asset recovery system 100 is illustrated in FIG. 8.An important aspect of the invention relates to the consolidation ofhardware components, such as the CPU. In particular, a single CPU 102 isused to control the entire asset recovery system 100. The CPU 102 may bea RISC processor, for example, an ARM 9 RISC processor, or may be aModel WMP100 wireless microprocessor, chip set, as manufactured byWaveCom SA. As mentioned above, the CPU 102 may include on-board UART112 and SSI 108 ports for interfacing the GPS Subsystem 118 and thecellular subsystem 110, respectively, with the CPU 112. The CPU 102 mayalso have on-board ADC 126, as well as on-board static RAM 128 and ROM130. The CPU 102 may also have an on-board real time clock (RTC) 132 anda digitally controlled crystal oscillator (DCXO) 134, controlled byexternal crystals 136 and 138, respectively. The crystal 136 is used togenerate the clock speed of the CPU 102. The crystal 138 is used fordevelopment of a real time clock signal. The CPU 102 may also include apower management unit (PMU) 136, an interrupt controller 138, a directmemory access (DMA) controller 140, internal debug software 142,internal timers 144, a digital signal processor (DSP) accelerator 146,general purpose input/output ports GPIO 148 in addition to the coreprocessor, identified with the reference numeral 150.

The asset recover system 100 may include various motion inputs frommotion devices that are used to control the power management of theasset recovery system 100. For example, an accelerometer 152 may coupleto the power management unit (PMU) 136, on-board the CPU 102. Thus,while the asset, e.g. a vehicle, is parked, power to the asset recoverysystem 100 can be reduced and later restored when motion of the asset isdetected. An additional motion sensor 154, for example, a vibrationsensor, may additionally be used to control the power management of theasset recovery system 100. As shown, the motion sensor 154 is interfacedto the CPU 102 by way of the on-board ADC 126.

One essential aspect of the asset recovery system 100 is the ability tocommunicate with a remote device. As shown, a cellular subsystem 110 maybe used for two way wireless communication between the asset recoverysystem 100 and a remote device, such as remote base station. Othercommunication systems, such as RF and satellite communication systemscan also be used.

The cellular subsystem 110 includes a cellular receiver 109 and acellular transmitter 111, which may included as a part of the WMP100,wireless microprocessor chip set, mentioned above. The cellularsubsystem 110 may be a multi-band system operable on various cellularfrequencies. As shown, a GSM (Global System for Mobile communications)cellular subsystem is illustrated which is operable on four (4)frequency bands: 850 MHz, 900 MHz, 1800 MHz and 1900 MHz. Othermulti-band and single band systems are also suitable.

The cellular subsystem 110 also includes a cellular antenna 156 that iscoupled to both the cellular receiver 109 and the cellular transmitterfor receiving and transmitting data with respect to a remote device. AnRF switch 158 is used to interface the cellular antenna to the cellularreceiver 109 and allows the various frequency bands to be selected. TheRF switch may, for example, may be included as a part of the WMP100,wireless microprocessor chip set, mentioned above The power amplifier124 is used to boost the signal from the cellular transmitter 111 beforeit is directed to the cellular antenna. The power amplifier 124 may be,for example, may included as a part of the WMP100, wirelessmicroprocessor, mentioned above Both the cellular transmitter 111 andthe cellular receiver 109 are interfaced to the CPU 102 by way of theon-board SSI 108.

The global position system (GPS) subsystem 118 includes a GPS antenna160 and the GPS receiver 114. The GPS antenna 160 and GPS receiver 114are configured to receive satellite signals from GPS satellites. The GPSreceiver 114, may be, for example, Model GNS-7560 chip set, asmanufactured by NXP Semiconductors. The GPS Search and Track CorrelatorEngine 107 correlates received signals with specific satellites so thatthe signals can be used to triangulate the position of the asset. GPSSearch and Track Correlator Engine 107 is part of the GPS receiver 114.The GPS subsystem is interfaced with the CPU 102 by way of the UART 112,on-board the CPU 102.

Electrical power for the asset recovery system 100 may be derived fromthe vehicle power system, for example, the 12 volt DC power system. Aconventional power connector may be used to connect the asset recoversystem 100. The vehicle power may be regulated by a voltage regulator126 and applied to the PMU 136. A battery charger 164 and a lithium ionback up battery 166 are provided. The back-up lithium ion battery 166provides power to the asset recovery system 100 when the vehicle powersupply is unavailable. During conditions when the asset recovery system100 is in a low power state, as will be discussed in more detail below,the battery charger 164 is used to charge the lithium ion back-upbattery 166. During states other than a low power state, the batterycharger 164 is configured to enable electrical power from the coaxialcable jack 162 to pass directly to the PMU, on-board the CPU 102.

There are various inputs 168 and outputs 170 to the CPU 102. Theseinputs and outputs are all interfaces with the CPU 102 by way of theon-board GPIO 148. The inputs to the CPU 102 include a signal from thevehicle ignition wire, which will either be high or low depending on thestate of the ignition system. Other inputs may optionally include aninput from a panic button and a temperature input. The panic buttonenables the user to signal the base station in the event of a medicalemergency or other emergency situation. An optional temperature inputmay be used to monitor the temperature of the CPU 102.

The asset recovery system 100 may provide one or more output signals.For example, the system 100 may provide a horn signal that can be usedto sound the vehicle horn as well as an LED signal that can be used toilluminate an LED in the vehicle in certain conditions. The assetrecovery system 100 may also provide a starter disable signal that canbe used to disable the vehicle starter (not shown).

In order for the base station to be able to distinguish the variousasset recovery systems in the field, a Subscriber Identity Module (SIM)172 which securely stores the service-subscriber key used to identify asubscriber of the asset recovery system. The SIM 172 is also used tostore user level configuration data and may be used to store loanaccount data for systems equipped with an optional loan obligationmanagement system.

Vehicle Ignition State Sensing

With the advent of wireless and GPS technology, a variety of assettracking applications are now possible. Vehicle tracking is a verycommon asset tracking application whereby the location of the vehicle isdetermined, recorded, and transmitted to a remote system. In addition tosuch location tracking, it is further desirable to record and determineother aspects such as the vehicle's utilization rate (% of time inoperation) and instantaneous operating state (at rest, moving, idling,marginal operation). It is also desirable to change the operatingprofile of the asset tracking device based up the instantaneouscondition. For example, a vehicle could be tracked more frequently whenit is moving or idling than when it is at rest. Or, the asset trackingdevice might wish to enter a low power consumption mode or even switchitself off in the event that the power supply it is connected to (thevehicle battery) is being depleted. When the vehicle resumes operation,the device can then jump to a more power intensive operation.

In order to provide these additional features, known systems useadditional inputs, such as an ignition input, temperature input,vibration sensor input, among others. However, this approach increasesthe cost and complexity of the installation process. In some vehicles, asignal representative of the state of the ignition system is directlyavailable from the vehicle ignition switch. In such systems, signalsrepresentative of the ignition states; “Ignition On”; “Ignition Off” arereadily available from the vehicle ignition switch. In other vehicles,an ignition input is not readily available or at all present in somevehicles to facilitate switching between different operating modes.Examples are such vehicles include motorcycles, scooters, all terrainvehicles, and watercraft. As such, asset recovery systems are heretoforenot known to be available for such systems.

Another problem with known asset recovery systems is that smallervehicles and watercraft are typically equipped with small batterieswhich can be depleted very quickly. Known systems solve this problem byforcing the system into non-operating sleep modes for extended periodswith a periodic wake up in which asset tracking related functions areperformed. However, entering extended sleep periods in a two-wireinstallation significantly impedes the ability of the asset trackingdevice to maintain and provide reliable information related to theinstantaneous operating state or even the overall utilization rate.

The asset recovery system 100 in accordance with the present inventionovercomes the challenge of two-wire installations by utilizing adedicated low-power circuit that monitors the voltage of the vehiclebattery to provide a signal representative of the instantaneousoperating state of the ignition. As is known in the art, the positiverail of the vehicle battery is normally higher when the vehicle ignitionis off. For example, in a typical vehicle with a nominal 12 voltbattery, the battery voltage is typically 12.5 volts dc when theignition is OFF and drops down to around 12.0 volts DC when the ignitionis ON. Vehicles with other nominal battery voltages experience similarhysteresis of the battery voltage from the ignition OFF state to theignition ON state. By measuring across the vehicle battery, the statusof the ignition system can easily be determined with a two-wire circuitwithout the need to access the vehicle ignition system. As such vehicleswith inaccessible ignition circuits, such as motorcycles, scooters, allterrain vehicles, and watercraft, can now be equipped with an assetrecovery systems.

The ignition status information is used to enter and exit variousoperating modes as well as lower the overall impact of the device on thepower supply of the vehicle thereby extending the life of the battery.In these cases, the device continues to operate in a higher power mode.

Exemplary Software Diagrams

FIGS. 9-13 illustrate exemplary software diagrams for the asset recoverysystem 100, illustrated in FIGS. 1-8. FIG. 14 illustrates an optionalloan obligation management system for use with the asset recovery systemin accordance with another aspect of the invention.

As mentioned above, different methods are known for detecting theignition state of a vehicle. In accordance with one embodiment of theinvention, one asset recovery system 100 can be utilized for both thehard-wired system, i.e. hard-wired to the ignition switch (not shown)and a system in which the ignition state is automatically determined byperiodically sampling the voltage across the primary winding of theignition coil. In accordance with an important aspect of the invention,the asset recovery system 1001 automatically detects which installationtype was used on the vehicle.

For vehicles in which access to the ignition switch (not shown) isavailable, the ignition switch, generally identified with the referencenumeral 168 (FIG. 8), is coupled to a GP I/O port 148. As is known inthe art, vehicle ignition switches have two (2) operating states:“Ignition On” and “Ignition Off”. As such, with vehicles with access tothe vehicle ignition system, the ignition states are readily available.In other vehicles, as mentioned above, in which the vehicle ignitioncircuit is inaccessible, the voltage applied to the ignition coil ismonitored and used to provide a signal representative of the ignitionstate.

In order to simplify the installation, a two (2) wire installation isused for both ignition state installation types. For vehicles withaccess to the vehicle ignition circuit, the two (2) wires are connectedto the ignition switch. For vehicles with no access to the vehicleignition switch circuit, the two (2) wires are connected across thevehicle battery. In order to further the complexity of the installationprocess, only two (2) wires are provided for external connection.Depending on the accessibility of the ignition circuit, the two (2)wires used to detect the ignition state can be connected to either theignition switch or the vehicle battery. In accordance with an importantaspect of the invention, the asset recovery system 100 automaticallydetermines the installation type. By providing only two (2) wires forexternal connection, the possibility of incorrect connections iseliminated.

Referring to FIG. 9, the system automatically detects whether the two(2) wires are connected to an ignition switch or across the vehiclebattery. This part of the system, identified with the reference numeral200, has two (2) operating modes: a hardwire ignition mode and a voltagehysteresis mode. The system samples the voltage available across thebattery; for example, by way of a GP I/O port 148 over a plurality ofconsecutive sample periods. If a voltage is sensed over two (2) sampleperiods, the system assumes a voltage hysteresis mode and sets a voltagehysteresis flag. In hard-wired installations, a voltage is not availableon the GP I/O port 148 (FIG. 8) for two consecutive sample periods. Insuch applications, a hard ignition mode flag is set.

Initially, on power-up, the system proceeds to step 206 and samples thevoltage at the GP I/O port 148 where the two (2) wires are connectedduring the first sample period. If a voltage is present, as determinedin step 208, the system sets the current sample to its equivalentdigital value by way of the analog to digital converter (ADC) on boardthe CPU 102 (FIG. 8) in step 210. Next in step 212, the system checkswhether a previous sampled voltage exists. Assuming that this is thefirst sample period, the system proceeds to step 214 and sets thevariable “Last Sample” to the digital value of the first sample in step214. The system then returns to step 206 for a second sample period.

During the second sample period, the a second sample of the voltage istaken at the GP I/O port 148 (FIG. 8) where the two (2) wires areconnected. If a voltage is present, as detected in step 208, the systemsets the second sample to its digital equivalent in step 210. If aprevious voltage sample exists, as determined in step 212, the systemsets a voltage hysteresis mode flag in step 216. On the other hand, if avoltage is not present in either first or second sample period, asdetermined in step 208, the system assumes a hard ignition mode and setsa hard ignition mode flag is set in step 218.

FIG. 10 is a software flow diagram for determining the state of theignition system. Once the installation type is learned by the system, asdiscussed above, either a hard ignition mode flag 240 or a voltagehysteresis mode flag 242 is set. Assuming the hard ignition mode flagwas set, the system continuously checks for changes to the ignitioninput status in step 244. As mentioned above, with a hard-wired ignitioninstallation, the ignition status is either Ignition On or Ignition Off,as indicated by the logic blocks 246 and 248, respectively. Each timethe ignition state changes, an ignition State Changed flag is set. Instep in step 250.

On the other hand, if the voltage hysteresis mode flag 242 was set, thesystem monitors the voltage at the port where the two (2) wire ignitionis connected and checks in step 252 whether the last sample voltage ≦the current sample voltage. The system then checks whether the lastsample voltage minus the current sample voltage > the ignition offthreshold voltage, for example 0.5 volts DC, assuming a 12 volt systemin which the battery voltage is 12.5 volts DC when the ignition is OFFand 12.0 volts DC when the ignition is ON, in step 254. If so, thesystem assumes the ignition state is Ignition Off in step 256. If not,the system assumes the ignition state changed in step 258.

As mentioned above, the system monitors the voltage at the port wherethe two (2) wire ignition is connected and checks in step 252 whetherthe last sample voltage ≦ the current sample voltage. If the lastsampled voltage < the last sample voltage, the system proceeds to step258 and determines whether last sample voltage minus the current samplevoltage > the ignition on threshold voltage. If so, the system assumesthe ignition state is Ignition On in step 260. If not, the systemassumes the ignition state changed in step 258.

FIG. 11 is a software flow diagram for managing an ultra-low power sleepmode. In order to conserve power particularly for vehicles withrelatively small batteries, the system includes a sleep management mode.The sleep management mode is used when there is minimal activity withrespect to the state of the ignition system. Depending on theinstallation type, different sleep durations may be used. Thus, in step262, the system determines whether the voltage hysteresis mode flag wasset. If not, the system assumes a hard wired mode and enables theignition input as an interrupt source in step 264. Thus, any changes inthe ignition state will interrupt the sleep mode and wake up the assetrecovery system 100. In step 266, an alarm is set for the current timeplus a relatively long duration, for example, 3 minutes. After the alarmis set, all peripherals are turned off in step 268. These peripheralsmay include LEDs within the vehicle. The GPS subsystem 114 may also beplaced in a hibernation mode. The system then enters the sleep mode 270;a relatively low power mode The system remains in the sleep mode untilwoken up, as indicated by the logic block 272, by way of an ignitioninterrupt, as indicated in step 274. The system exits the sleep mode instep 276. Otherwise the system remains in the sleep mode.

On the other hand, if the system determines in step 262, that thevoltage hysteresis flag 216 is set, the system checks in 278 whether thecurrent ignition state is the same as the old ignition state. If not,the system exits the sleep mode in step 276. In other words, if thesystem is in the voltage hysteresis mode, any change in the ignitionstate causes the system to exit the sleep mode. If the ignition statehas not changed, an alarm is set in step 280 for the current time plus arelatively short duration, for example, 30 seconds. At the expiration ofthe time period, the system proceeds to step 268 and turns off allperipherals and enters the sleep mode in step 270. The system may thenwoken up by interrupt or in a predetermined time interval. Inparticular, if the voltage hysteresis mode flag was set, as determinedin step, the system checks in step 282 whether a predetermined timeinterval has elapsed, for example, whether a time interval, identifiedas the “wakeup count” has expired where the wakeup count >longduration/short duration. If so, the system exits the sleep mode.Otherwise, the system stays in the sleep mode.

FIG. 12 is an exemplary software flow diagram illustrating the GPSposition calculation. The GPS system is used to determine the positionof the vehicle. GPS satellites broadcast two types of data: Almanac dataand Ephemeris data. Almanac data relates to course orbital parameterdata for all of the GPS satellites in the constellation. Each satellitebroadcasts Almanac data for all of the satellites in the constellation.Almanac data is not considered to be very precise and is consideredvalid only for a few months. Ephemeris data by comparison is veryprecise orbital and clock correction for each satellite and is necessaryfor precise positioning. Each satellite broadcasts only its ownEphemeris data. This data is only considered valid for about 30 minutes.The Ephemeris data is broadcast by each satellite every 30 seconds. Whenthe GPS is initially turned on after being off for more than 30 minutes,it “looks” for the satellites based on where it is based on the almanacand current time. With this information, appropriate satellites can beselected for initial search³. ³ “Almanac and Ephemeris Data as used byGPS receivers”, by Joe Mehaffey, (4 Jul. 1998),http://gpsinformation.net/main/almanac.txt

Based on the above, the system checks in steps 286 whether it has thecurrent time. As mentioned above, the CPU 102 (FIG. 8) includes a realtime clock 132, which can be used for the current time. The GPS Receiver114 receives Almanac data directly from the satellites, as mentionedabove. The Almanac data is saved in Flash memory 106 in step 290. Basedon the real time and the almanac data, the system predicts expectedsatellites in step 292 and searches for those satellites in step 294. Instep 296, the system checks whether the expected satellites were found.If either there is no real time data; no valid Almanac data or theexpected satellites cannot be found, the system searches for anysatellites in step 298.

If the expected satellites are found, as determined in step 296, thesystem checks in step 300 whether valid ephemeris data has been foundfor three (3) or more satellites. If so, the system saves the ephemerisdata is found, it is stored in the Flash memory 106 (FIG. 8) in step302. In step 304, the vehicle position is triangulated based on theephemeris data. The system then checks in step 306 whether the positionis valid by comparing it with the last known position of the vehicle. Ifthe position is not determined to be valid, real time and almanac datais decoded in steps 316 and 318 from the satellite signals located instep 298. The decoded almanac data is then stored in the flash memory106 (FIG. 8) and the system proceeds to calculate the vehicle positionas indicated in steps 292-304, as discussed above.

If the position is determined to be valid, the system next checks instep 308 whether the solution is a high precision solution in step308.), for example, as provided by the GPS chip set mentioned above. Ifso, the position is stored in step 310 and the system enters the sleepmode in step 312 for duration as determined by the sleep management mode218 (FIG. 11).

On the other hand, if the position is not considered to be a highprecision solution, as determined in step 308, the system checks whetherthe search window has expired in step 314. If not, the system returns tostep 284. If so, the system enters the sleep mode.

The main state machine, generally identified with the reference numeral320, is illustrated in FIG. 13. As used herein, the system is configuredas a master server network. The asset recovery system 100 is the clientwhich communicates with a remote server (not shown). Initially the powercondition of the asset recovery system is checked, for example, bymeasuring its power input in step 322. If the power condition is notvalid, the system proceeds to step 324 and enters the sleep mode for aduration as determined by the sleep management system 218.

If the power condition is valid, the system checks its inputs.Specifically, the system checks in step 324 whether the ignition statehas changed. If so, the system checks in step 326 whether the assetrecovery system 100 is configured to allow ignition messages to be sentto the server. In particular, on power-up, the asset recovery system 100fetches its configuration from a remote server. The system 100 thenstores its configuration and sets a flag at the server If the assetrecovery system 100 is properly configured, the system adds a locationpacket to the ignition message so that the ignition message can becorrelated to the vehicle position in step 328. In step 330, the systemchecks whether the state of the panic button has changed. If so, thesystem checks in step 332 whether the asset recovery system 100 isconfigured to allow panic messages to be sent to the server. If so, thesystem adds a location packet to the panic message so that the change ofstate of the panic button can be correlated to the vehicle position instep 328. In step 334, the system checks whether the state of the motionsensor has changed. If so, the system checks in step 336 whether theasset recovery system 100 is configured to allow motion messages to besent to the server. If so, the system adds a location packet to thepanic message so that the change of state of the motion sensor can becorrelated to the vehicle position in step 328.

In step 338, the system checks whether any commands have been receivedfrom the server (not shown). If so, the system processes the command instep 340. Exemplary commands may include signals to sound the vehiclehorn; disable the vehicle starter; or illuminate an LED in the vehicle.In step 342, the system checks whether the asset recovery system isconfigured to allow command type messages. If so, the system proceeds tostep 328.

If there are no commands from the server, the system checks in step 344to determine whether there are packets in the queue ready to be sent tothe server over the cellular network. If so, the system is connected tothe network in step 346 and connects with the server in step in step348. In step 350, the system transmits the packets to the server.

Loan Obligation Management System

FIG. 14 is a software flow diagram of the loan obligation managementsystem in accordance with one aspect of the present invention. In thisembodiment of the invention, the asset recovery system 100 is providedwith additional functionality. In this embodiment of the invention, thefinance company involved with the financing of the vehicle uses theasset recovery system 100 for loan obligation management. In particular,assuming a customer purchases a vehicle or other asset as indicated instep 352 and establishes a loan for purchase of the vehicle in step 354.As part of the loan conditions, an asset recovery system 100 isinstalled in the vehicle in step 356. In step 358 an account number forthe loan is established and transmitted to the system server in step360, thereby establishing the account on the server.

In this system the finance company determines a collection strategy, asindicated by the logic block 364. Based upon changes in the paymenthistory by the debtor, the finance company may determine a that a changein the collection strategy needs to be performed, as indicated by thelogic block 366 and sends the server a message with the account numberand the action that needs to be taken in step 368. Upon receipt of themessage from the finance company, the server looks up the account numberand the associated MSISDN number of the cellular device within the assetrecovery system 100 in the vehicle in step 370 and transmits the messagein step 372. The message is stored as a command in the SIM card 172(FIG. 8). In step 376, the system performs the command when the ignitionis turned on. In step 378, the system acknowledges to the financecompany that that the requested action has been taken.

An exemplary embodiment of the loan obligation management system mayinclude management through an entire payment cycle. In particular,assuming that a loan payment is due, as indicated by the logic block380, a payment reminder is enabled in the vehicle. The payment remindermay be illumination of an LED in the vehicle. If the payment is made, asindicated in step 384, the payment reminder is disabled in step 386.However, if payment is not made, the vehicle is disabled, for example,by disabling the starter in step 388. In that situation, the loan statuswould be considered to be in default and sent to collections, asindicated by the logic blocks 390 and 392.

Obviously, many modifications and variations of the present inventionare possible in light of the above teachings. Thus, it is to beunderstood that, within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described above.

What is claimed and desired to be secured by a Letters Patent of theUnited States is: 1-20. (canceled)
 21. A method for managing a loanobligation of an asset which includes: a communication system forenabling communications between said asset and a remote device; a systemfor detecting the state of said asset and communicating the state ofsaid asset to said remote device by way of said communications system; asystem for providing an indication of a payment due; and a system forenabling said asset to be disabled based upon a command from said remotedevice, the method comprising: (a) sending a payment reminder over saidcommunication system to said asset providing an indication of a loanobligation; (b) disabling said payment reminder as a function of saidstate of said asset by way of said communication system when a paymentis made; and (c) disabling said asset as a function of said state ofsaid asset by way of said communication system when a payment is notmade.
 22. A system for managing a loan obligation of a vehicle, thesystem comprising: a communication system for enabling communicationbetween a vehicle and a remote device; a system configured to monitorthe ignition state of the vehicle; and a system responsive to commandsfrom said remote device received from said communication system andconfigured to disable the vehicle in response to receiving a disablecommand or provide a signal that a payment is due as a function of theignition state of the vehicle.